In designing and maintaining information systems, attention has been paid to the establishment and smooth operation of connections between different systems. Separately located systems have often been implemented using rather many different methods and incompatible hardware of different type. It has been laborious and time-consuming, if at all possible, to convert the different systems into compatible ones.
Consequently, many different hardware and system manufacturers have developed a common architecture called CORBA (Common Object Request Broker Architecture) to enable different computer systems implemented using different programming languages to communicate with each other in a flexible manner. The CORBA specifies a GIOP (General Inter-ORB Protocol) protocol, and application of this protocol enables devices of different type and programs programmed in different programming languages to communicate. The GIOP protocol is a common protocol, from which an IIOP (Internet Inter-ORB Protocol) is has been developed particularly for the Internet environment. Further information on the CORBA can be obtained e.g. from a specification called The Common Object Request Broker: Architecture And Specification., Revision 2.0, and Paragraph 2 thereof: CORBA Overview, published by OMG (Object Management Group), a group which created the architecture. The specification can also be found at www.omg.org.
The CORBA has been developed for systems that are fixedly interconnected through an unspecified network. When the protocol was being designed, little attention was paid to transmission path capacity and to the possibly changing transmission paths, the main focus being the creation of a safe and flexible protocol. Since wireless communication has recently become increasingly popular, computers and devices whose only or main connection to other networks is a wireless network, such as a GSM, GPRS or UMTS, have also started using information systems and different software.
Examine a simplified example of the CORBA architecture in FIG. 1. The figure shows software or an application 100 and a name server 102. A name server is typically a server implemented by a computer and software, into which applications providing different services can register. In the example of FIG. 1, an application 104 providing a service is registered in the name server. Physically, an application is typically software arranged in computer hardware. When the application registers in the name server, it indicates its address, i.e. how the application can be accessed. The name server maintains a list of software items providing different services, including the addresses of the software items. When the software 100 needs a service, it establishes a connection 108 to the name server 102 and indicates that it needs a particular service. The name server searches its list for such a service and replies by issuing the address of the application providing the desired service. Next, the software may transmit a service request 112 to the application 104 providing the service.
A special feature of the wireless telecommunication systems, and cellular radio systems in particular, is that the applications run in the terminals of the systems do not know their own address, which would enable applications in other devices to access a particular application. This is because the terminals do not know their own number, i.e. their MSISDN (Mobile Subscriber Integrated Services Digital Network number) number. Examine a GSM system as an example; a terminal knows its own IMSI identifier, which is stored on the SIM card in the terminal. If necessary, the GSM network, in turn, is responsible for finding out the connection between the IMSI and the actual telephone number (MSISDN). However, the IMSI number cannot be used as the address of the terminal, but only the MSISDN number can be used as such.
The CORBA was originally developed for systems that did not take mobility or special features of the radio systems into account. Consequently, addresses to be attached to method calls and other communication e.g. in connection with service registration present a problem. Storing the MSISDN number of the terminals in the terminals is not necessarily a good idea since the number would no longer apply e.g. after installing a new SIM card.